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1.  INTRODUCTION 

•  This  Quarterly  Technical  Report,  No.  10,  describes  aspects 
of  ©«r^work  on  the  ARPA  Computer  Network  during  the  second 
quarter  of  1971. 

Our ^efforts  during  this  period  were  devoted  primarily, 
though  not  exclusively,  to  the  Terminal  IMP.  The  quarter  saw 
the  ARPA  Network  remain  stable  in  size;  we  used  thlsopportu- 

.....  V  / 

nity^  to  study  traffic  in  the  net,  to  plan  and  Implement  improve¬ 
ments  in  the  operation  of  the  Network  Control  Center  at  BBN,  to 
discover  and  correct  some  minor  bugs  in  the  operational  IMP 
hardware  and  software,  and  to  continue  investigation  of  routing 
problems.^ 

'\ 

During  the  quarter  our  participation  in  the  Network  Working 
Group  increased  substantially,  with  several  members  of  the  staff 
devoting  significant  amoiints  of  time  to  Working  Group  subcom¬ 
mittees  and  to  the  preparation  of  Network  documents.  Some  of  our 
activities  in  this  area  are  described  in  Section  2. 

WorK  on  the  Terminal  IMP  progressed  on  several  fronts.  By 
the  end  of  the  quarter  we  had  received  three  additional  3l6s 
from  Honeywell.  Two  Multi-Line  Controllers  are  in  final  assembly 
and  three  more  are  under  construction.  A  variety  of  terminal 
devices  have  now  been  tested  with  the  Terminal  IMP  hardware  and 
prototype  software.  Significant  portions  of  the  Terminal  IMP 
software  have  been  written  and  partially  debugged,  and  the 
Terminal  IMP  command  language  has  been  largely  specified.  By  the 
end  of  the  quarter  a  terminal  connected  to  the  prototype  Terminal 
IMP  had  successfully  logged  into  the  BBN  TENEX  system.  All  of 
these  developments  are  covered  in  some  detail  in  Section  3. 
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2.  NETWORK  WORKING  GROUP  PARTICIPATION 

Early  in  1969  the  Network  Host  organizations  formed  a  Network 
Working  Group  (NWG) ,  under  the  chairmanship  of  Steve  Crocker,  to 
facilitate  the  exchange  of  ideas  about  network  use  and  to  formu¬ 
late  specifications  for  Host-to-Host  communications.  Although 
BBN  has  participated  in  the  activities  of  the  NWG  since  its 
inception,  during  the  last  two  quarters  we  have  significantly 
expanded  our  participation,  and  have  been  particularly  Involved 
in  the  following  areas: 

1)  Host-to-Host  Protocol:  The  so-called  Host-to-Host 
Protocol  was  the  first  protocol  developed  by  the  NWG. 

It  is  primarily  concerned  with  the  method  of  establish¬ 
ing  process-to-process  "connections"  over  the  network, 
and  with  the  control  of  data  flow  over  these  connections. 
(It  is  not  generally  concerned  with  the  syntax  or  seman¬ 
tics  of  the  data  being  transferred  over  the  connections.) 
The  first  "official"  specification  of  this  protocol  was 
published  in  mid-1970;  by  early  1971  various  problem 
areas  of  the  original  specification  were  becoming 
apparent.  We  have  participated  in  a  committee  of  the 
NV/G  v/hich  was  formed  to  revise  the  protocol;  we  also 
assumed  responsibility  for  formalizing  and  publishing 

a  revised  protocol  specification. 

2)  Resource  Notebook:  If  the  network  is  actually  to  be 
used  for  resource  sharing  it  is  essential  that  each  Host 
organization  have  convenient  access  to  a  description  of 
the  resources  available  at  other  sites.  V/ith  this  in 
mind  we  have  undertaken  the  preparation  of  a  document 
entitled  the  "ARPA  Network  Resource  Notebook"  which  is 
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Intended  to  provide  summary  information  for  each  Host 
site,  as  well  as  references  to  more  detailed  site 
documentation.  We  prepared  an  outline  of  the  summary 
information  desirable,  and  requested  each  site  to  supply 
that  information  directly  to  us.  The  information  was 
edited  into  a  uniform  format  at  BBN,  and  the  original 
Resource  Notebook  (representing  13  Hosts)  was  released 
via  the  Network  Information  Center  at  SRI  in  April  of 
this  year.  We  have  Just  completed  work  on  the  first 
revision  of  the  Notebook  which  now  provides  summary 
information  for  a  total  of  17  (of  19)  Host  organizations. 

3)  TELNET  Protocol:  The  TELNET  protocol  specifies  a  method 
for  making  a  terminal  (or  process)  at  a  ’’using”  site 
appear,  to  the  system  or  to  a  process  at  a  ’’serving” 
site,  logically  equivalent  to  the  type  of  terminal 
normally  used  at  the  serving  site.  This  is  accomplished 
by  specifying  the  characteristics  of  a  ’’Network  Virtual 
Terminal”  (NVT) ;  each  Host  is  responsible  for  mapping 
between  locally-used  conventions  (character  codes,  echo 
modes,  etc.)  and  NVT  conventions.  We  have  been  heavily 
Involved  in  the  committee  responsible  for  the  specifi¬ 
cation  of  TELNET,  since  Terminal  IMPs  will  most  commonly 
operate  under  this  protocol. 

i|)  Data  and  File  Transfer  Protocols:  We  have  also  been 

represented  on  the  committee  of  the  NWG  responsible  for 
proposing  protocols  for  data  transfer  and  file  transfer. 
As  with  TELNET,  the  protocols  finally  adopted  by  the 
NV/G  will  significantly  affect  the  performance  of  the 
Terminal  IMPs. 
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In  addition  to  the  specific  areas  described  above,  we  have 
somewhat  expanded  our  participation  in  the  quarterly  NWG  meetings, 
and  have  undertaken  some  specific  small  tasks,  such  as  determining 
and  summarizing  site  status,  at  the  request  of  the  Network  Working 
Group . 
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3.  TERMINAL  IMP 

3.1  Hardware  Development 

Early  in  the  last  quarter  we  reviewed  aspects  of  the  Terminal 
IMP  software  requirements  including  device  buffering  for  medium 
and  high  speed  terminals,  character  code  translation,  and  the 
various  Host-to-Host  protocols  with  which  the  Terminal  IMP  must 
comply.  This  review  made  clear  to  us  that  the  originally  planned 
16K  memory  capacity  would  be  Insufficleno,  and  the  decision  was 
made  to  upgrade  the  memory  capacity  to  20K.  The  additional 
memory  module  will  physically  occupy  space  at  the  .top  of  the 
highboy  rack  formerly  allocated  to  modem  and  Host  interfaces. 

Thus,  the  initial  Terminal  IMP  will  be  physically  limited  to 
interfacing  either  with  three  modems  or  with  two  modems  and  one 
Host.  We  Intend  to  provide  a  version  of  the  Terminal  IMP  with 
an  additional  half-rack  which  will  modify  these  limitations. 

Memory  retrofits  have  been  ordered  for  the  prototype  Terminal 
IMP  and  the  Terminal  IMP  scheduled  for  field  installation,  both 
of  which  were  delivered  to  BBN  some  time  ago.  During  this 
quarter  we  took  delivery  of  three  additional  H-316  Terminal  IMP 
computers  from  Honeywell;  these  machines  are  all  equipped  with 
the  full  20K  memories.  Construction  then  proceeded  through  the 
rest  of  the  quarter  on  all  of  the  first  four  deliverable  Terminal 
IMPS,  with  the  first  delivery  scheduled  for  the  middle  of  the 
third  quarter  of  1971.  Work  centered  on  detailed  docum.entatlon 
of  mechanical  and  electrical  assemblies,  selection  and  testint^ 
of  components  and  assemblies,  selection  of  qualified  vendors, 
and  final  mechanical  and  electrical  design  cleanup. 

The  prototype  Multi-Line  Controller  (MLC)  common  logic  unit 
and  40  Line  Interface  Units  (LIUs)  were  completed  and  checked 
out.  In  particular,  the  MLC  has  run  successfully  at  all  speeds 
up  to  and  including  19.2  kilobits  and  with  several  combinations 
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of  mixed  speeds.  The  MLC  has  been  tested  with  LIUs  in  each  of 
the  64  possible  slots,  although  for  complete  testing  we  must 
await  the  fabrication  of  additional  LIUs.  Using  a  prototype  test 
program  we  have  operated  the  MLC  at  data  rates  well  in  excess  of 
the  Terminal  IMP  design  goal  (100  Kilobits  total)  and  observed 
gradual,  rather  than  catastrophic,  degradation. 

A  second  MLC  has  been  fabricated  and  partially  tested  in  the 
same  manner  as  the  prototype,  and  three  additional  MLCs  were  under 
constructloii  by  the  end  of  the  quarter.  In  addition,  a  test  pro¬ 
gram.  for  the  MLC  was  partially  completed  and  run.  This  test  pro¬ 
gram  will  be  used  in  the  production  of  MLCs  as  an  analog  to 
IMPTEST  in  the  production  of  IMPs. 

3.2  Terminal  Checkout 

During  the  last  quarter,  the  x  Tallowing  terminals  were  re¬ 
ceived  and  tested  with  the  BBM  Multi-Line  Controller  and  a  proto¬ 
type  test  program. 

ODEC  Line  Printer  and  Line  Adapter 
Execuport  Terminal 
IMLAC  PDS-1  Graphics  Terminal 
TTY  Model  33 

Infoton  Alphanumeric  CRT  Terminal  Vista  1-H 
IBM  2741  Communications  Terminals 


ODEC 

The  ODEC  line  printer  is  a  200-line-per-minute ,  132- 
column  tabletop-size  chain  printer.  It  prints  a  64- 
character  subset  of  ASCII.  In  order  to  provide  the 
capability  of  operating  as  a  stand-alone  remote 
terminal  at  the  end  of  a  dial-up  telephone  line,  a 
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Communications  Line  Adapter*  was  ordered  from  ODEC 
with  the  printer.  The  adapter  provides  a  256-character 
buffer  to  allow  for  instantaneous  differences  between 
the  character  input  and  character  printing  rates  which 
occur  because  of  line  length  variations.  The  200-line- 
per-minute  printing  rate,  if  full  132-character  lines 
are  used,  is  equivalent  to  an  asynchronous  data  rate 
of  approximately  il600  bits  per  second.  In  practice, 
since  full  132-character  lines  are  not  always  used,  the 
rate  of  successive  lines  must  not  exceed  approximately 
3  per  second  (200  lines/minute)  long  term  average  or 
the  Line  Adapter  buffer  will  overflow  and  data  will  be 
lost.  In  the  event  that  the  buffer  nears  overflow 
(16  to  31  character  spaces  left)  a  reverse  channel 
signal  is  furnished  by  i;hc  adapter.  This  signal  will 
be  used  to  temporarily  halt  the  flow  of  data  from  the 
■MLC  computer  program. 

The  printer  has  been  operated  at  I8OO  bits/second,  but 
the  rate  of  the  line  adapter  may  be  strapped  to  600, 
1200,  or  2^00  bits/second,  if  desired.  A  rate  of  1200 
is  anticipated  for  use  over  the  dial-up  phone  system 
using  202c  type  modems  and  this  mode  will  be  tasted 
shortly. 

Lxecuport 

The  Sxecuport  300  is  a  stand-alone  portable  communi¬ 
cations  terminal  with  a  built-in  acoustic  coupler  for 
use  over  the  dial-up  telephone  system.  It  uses  ASCII 
characters  at  rates  of  110,  150,  and  300  bits/second, 
determined  by  a  switch  set  by  the  operator.  Printout 
is  a  5  X  7  dot  matrix  on  thermal-sensiti ve  paper 
(single  copies  only). 
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IMLAC  PDS~1 

The  IMLAC  PDS-1  is  an  intelligent  (i.e.,  it  contains 
a  computer)  terminal  which  is  designed  for  graphics 
uses.  The  computer  has  a  l6-bit  word  and  our  version 
has  of  core.  The  terminal  may  be  used  for  alpha- 
numerics  if  desired.  The  set  of  characters  used 
depends  on  the  particular  program  used  in  the  computer. 

In  the  tests  of  PDS-1  with  the  MLC,  the  standard  IMLAC 
edit  program  was  used  (implies  ASCII  characters). 

The  transfer  data  rate  of  the  PDS-1  is  defined  by 
strapping  and  components  on  a  printed  circuit  card. 

We  have  operated  at  110  bits/second,  1800  bits/second, 
and  9600  bits/second. 

Infoton  Vista  l-'H 

This  is  an  alphanumeric-only  CRT  terminal  which  uses 
asynchronous  ASCII  characters.  The  data  rate  is  switch 
selectable  from  110  bits/second  to  4800  bits/second. 

The  device  has  80  columns  and  20  lines.  It  has  oeen 
tested  at  all  its  switched  rates  with  the  MLC. 

IBM  2741 

Two  versions  of  IBM  2741  were  leased  from  IBM  for  test- 
irig  with  the  MLC,  a  Correspondence  code  version  and  a 
PTTC/EBCD  code  version.  These  terminals  have  a  rate  of 
134.5  b'.ts/second  and  are  half  duplex  only.  A  reverse 
break  option  will  soon  be  installed  in  the  terminals 
and  tested  with  the  MLC.  To  date,  these  terminals  present 
the  largest  problems  in  operation  because  of  the  code  sets 
used  (both  non-ASCII)  and  also  the  complicated  handshaking 
procedure  necessary  to  control  the  terminals. 
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No  special  problems  were  encountered  with  any  of  the 
terminals  in  testing.  All  MLC  rates  from  110  baud  to  19.2 
kilobaud  were  exercised  by  various  combinations  of  terminals. 
Several  of  the  terminals  were  also  exercised  by  connecting  them 
to  the  BBN  TENEX  System.  Telephone  oomoany  modems  of  the  10 3A 
and  202C  type  were  installed  in  the  IMP  room  and  tests  were  con¬ 
ducted  to  insure  their  compatibility  with  the  MLC.  Once  again 
no  significant  problems  arose  and  several  terminals  were  con¬ 
nected  to  the  MLC  and  operated  using  these  modems. 

3.3  Terminal  IMP  Control  Language 

The  prototype  Terminal  IMP  was  successfully  placed  on  the 
ARPA  Network  and  a  user  was  able  to  log  into  BBN  TENEX  using  a 
prototype  of  the  Terminal  IMP  program.  The  function  of  this 
program  is  to  transmit  data,  primarily  characters,  from  a 
terminal  to  some  remote  Host  and  to  return  the  Host’s  response; 
this  activity  is  expected  to  be  part  of  an  interactive  dialogue 
in  most  cases.  To  perform  this  function  the  Terminal  IMP  soft¬ 
ware  needs  to  know  the  values  of  several  parameters  for  each 
device;  the  user  will  be  expected  to  provide  these  parameters 
via  the  Terminal  IMP  control  language,  which  is  described  below. 

It  should  be  noted  that  this  control  language  is  still  under 
development  and  subject  to  change,  but  is  expected  to  be 
essentially  as  described  here  at  the  time  of  delivery  of  the 
first  Terminal  IMP. 

As  the  Terminal  IMP  passes  characters  from  a  terminal  to 
the  net  it  briefly  Investigates  them  to  see  if  they  are  one  of 
three  special  characters  which  require  more  examination.  These 
characters  are  LINEFEED,  and  END-OF-MESSAGE .  (A  ’’delete  last 
character”  character  and  a  ’’cancel  line"  character  are  expected  to 
be  added  in  the  future.)  It  should  be  emphasized  here  that  the 
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interpretation  of  these  special  characters  depends  on  mode 
parameters,  and  that  ii  is  possible  to  set  the  modes  so  that  the 
characters  are  not  Interpreted  at  all.  In  this  latter  mode,  the 
terminal  passes  straight  binary  to  the  Host. 

LINEFEED  and  END-OF-MESSAGE  may  be  used  to  signal  the  IMP 
that  it  is  time  to  pack  the  characters  it  has  been  accumulating 
into  a  message  and  dispatch  them  to  the  Host.  This  option  might 
be  used  in  line-at-a-time  operation.  The  special  characters  will 
be  included  at  the  end  of  the  message.  See  the  TRANSMIT  command 
(below)  for  additional  details. 


The  0  signals  the  beginning  of  a  command  to  the  Terminal 
I.MP.  It  may  occur  anywhere  in  the  input.  All  the  characters 
from  the  @  to  the  command  terminator  will  b  .•  Interpreted  as  a 
command  to  the  IMP.  They  will  not  be  put  in  the  message  buffer 
and  the  remote  Host  will  never  see  them.  The  command  terminator 
is  normally  the  pair  "CARRIAGE-RETURN  -  LINEFEED".  The  only 
exception  to  this  rule  is  the  command  which  puts  a  single  Q 
in  the  regular  output  buffer.  This  exception  allows  one  to  send 
this  special  character  on  to  the  Host  if  @  is  part  of  its 
control  set,  (This  has  nothing  to  do  »..ith  sending  binary, 
however. ) 

The  regular  commands  consist  of  the  following  elements  in 
the  indicated  order: 


3 

<DEVICE  NUMBER> 
<COMMAND  TYPE> 
<NUMERIC  PARAMETER> 
CARRIAGE-RETURN 
LINEFEED 


required 

optional 

required 

sometimes  required 

required 

required 
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An  example  of  a  regular  command  is 

@  RECEIVE  FROM  HOST  6  CARRIAGE-RETURN  LINEFEED 

The  <DEVICE  NUMBER>  specifies  which  device  the  user  is 
setting  parameters  for.  Usually,  it  will  be  his  own  device,  in 
which  case  it  may  be  omitted.  However,  it  will  be  necessary  to 
set  up  parameters  for  devices  like  card  readers,  tape  drives, 
etc.  which  cannot  set  their  own  modes.  Such  an  option  requires 
protection,  which  will  take  the  following  form; 

1)  The  executive  teletype  can  change  anyone’s  parameters. 

2)  Certain  devices  (such  as  line  printers) 

can  be  captured  by  another  device  if  they  are  in  the 
free  .state.  Once  captu”''-d  only  the  capturing  device 
can  set  and  change  theij-  parameters  until  they  are 

freed. 

In  what  follows  the  device  number  will  be  omitted  from  all 
examples  and  discussion  unless  it  plays  an  unusual  role.  The 
commaind  terminator  will  be  omitted  as  well. 

The  <COMMAND  TYPE>  consists  of  one  to  four  English  words.  The^e 
words  are  carefully  chosen  so  that  commands  can  be  uniquely 
distinguished  by  the  first  letter  of  each  word.  This  has  two 
benefits:  the  IMP  can  save  valuable  core  by  only  investigating 
the  first  letter  after  each  space  (or  set  of  spaces),  and  a 
fluent  user  can  abbreviate  his  commands;  the  example  above 

becomes 


a  R  F  H  6 
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Commands  to  Set  Parameters  for  Connections 
@  HOST  H 

@  SEND  TO  SOCKET  # 

@  SEND  ON  LINK  # 

@  RECEIVE  FROM  HOST  # 

@  RECEIVE  FROM  SOCKET  # 

These  commands  set  par;'meters  for  the  terminal  in  preparation  for 
establishing  communications  with  a  remote  process.  The  establish¬ 
ment  of  the  parameters  does  not  initiate  the  protocol  to  establish 
the  connection,  but  it  will  result  in  the  exchange  of  protocol 
messages  tc  close  a  previously  existing  connection.  A  fundamental 
system  constraint  is  that  each  device  participates  in  only  a  single 
connection  at  a  time. 

The  HOST  command  is  shortened  because  it  is  part  of  the 
standard  TELNET  login  sequence. 

The  parameter-setting  commands  do  not  permit  establishing 
the  receive  link  since,  by  convention,  the  receive  link  will 
always  be  the  device  number  plus  two.  Similarly,  the  local  socket 
numbers  v/ill  be  a  fixed  multiple  of  the  device  number,  with  the 
"gender"  bit  set  appropriately. 

The  Terminal  IMP  initially  ignores  the  niceties  of  protocol 
and  simply  prints  any  incoming  message  on  the  device  indicated 
by  the  link.  Establishing  RECEIVE  parameters  amounts  to  locking 
out  messages  from  all  but  the  authorized  source.  The  Terminal 
IMP  also  initially  ignores  protocol  on  the  transmit  side,  per¬ 
mitting  the  user  to  establish  the  transmit  link.  (Protocol  re- 
v-juires  the  RECEIVE  side  of  a  connection  to  specify  the  link.) 
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The  Terminal  IMP  Imposes  only  the  constraint  that  a  device  win 

not  be  allowed  to  establish  the  same  Host  and  link  already  used 

y  another  device.  The  commands  described  here  allow  complete 
-n«« 

protocol  options  to  be  described  later  will  automatically  supply 
several  of  the  parameters. 


It  is  reasonable  to  also  have  an  "unspecified-  state  for  the 
ransmlt  parameters  to  protect  against  operator  error.  For 
example  when  a  user  changes  the  remote  Host  the  link  value 
will  automatically  be  set  to  "unspecified". 


Commands  to  Control  Transmission 


3  transmit  every  character 

9  TRANSMIT  EVERY  » 

9  TRANSMIT  ON  ENO-OF-MESSAGE 
9  TRANSMIT  ON  LINEFEED 
9  TRANSMIT  ON  NO  CHARACTER 

9  transmit  now 


The  Terminal  IMP  needs  to  know  how  many  characters  to 
accumulate  before  trying  to  send  off  a  message.  The  user  has 
hree  basic  options:  he  can  specify  a  count  of  characters 
(EVERY  CHARACTER  amounts  to  a  count  of  one),  n  he  doesn't 
specify  a  count,  the  IMP  supplies  some  large  number.  The  user 
can  also  specify  termination  on  either  of  two  special  characters 
(END-OF-HESSAGE  and  LINEFEED).  He  may  set  both  or  neither  (NO 
HARACTER)  If  he  wishes.  The  third  option  Is  to  speclfv  the  end 
Of  each  message  manually  (TRANSMIT  NOW).  However,  the  IMP  may 
e  unable  to  send  the  message  at  the  time  specified  by  the  user. 

.  n  this  happens,  the  message  will  be  sent  at  the  next  oopor- 

timr"’THr  Characters  received  up  to  that 

time.  This  is  In  line  with  the  Host  protocol  philosophy  which 

asserts  that  message  boundaries  should  have  no  particular  slg- 
nificance.  ^ 
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Commands  to  Set  Echo  Mode 

0  ECHO  ALL 

0  ECHO  NONE 

@  ECHO  HALF-DUPLEX 

These  commands  tell  the  Terminal  IMP  what  characters  to  echo  to 
the  device.  ALL  causes  all  characters  input  from  the  terminal 
to  be  echoed  (full  duplex  with  local  echoing).  NONE  causes  none 
of  the  characters  which  are  passed  to  the  Host  to  be  echoed  (full 
duplex  with  remote  echoing);  however,  all  characters  which  are 
intercepted  by  the  Terminal  IMP  are  echoed.  HALF-DUPLEX  causes 
the  Terminal  IMP  to 

•  echo  nothing 

•  ignore  input  while  output  (to  the  terminal)  is  in  progress 

•  prevent  output  while  input  (from  the  terminal)  is  in 
progress 

Commands  to  Transmit  Special  TELNET  Codes 

0  SEND  SYNC 

0  SEND  BREAK 

The  TELNET  protocol  includes  the  definition  of  two  special 
characters  which  must  be  under  the  control  of  the  user.  The 
’’sync"  character  is  inserted  in  the  data  stream  when  an  ’’Interrupt’ 
signal  is  sent  on  the  ’control  link"  from  one  Host  (in  tjnls  case 
the  Terminal  IMP)  to  another;  it  allows  the  receiving  Host  ^o 
synchronise  the  data  stream  with  the  control  stream.  The  "break’’ 
character  is  used  to  gain  the  attention  of  the  serving  Host. 


/ 
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Commands  to  Activate  Terminal  IMP  Control 

@  INTERCEPT  ESCAPE 
@  INTERCEPT  NONE 


These  commands  determine  whether  the  special  "F<,r^an 

H  r  "»ap « 1.  int,“ 

thrN™.  "»»'  “•  '•■■•fw  with 

none  as  It  can  dlaconnaot  M.  fro.  hit  Tcr.lnal  IMP 

It  1.  necasarp,  nca,.,.  ' 

Commands  to  Set  Device  Parameters 


@  DEVICE  RATE  # 

@  DEVICE  CODE  ASCII 
@  DEVICE  CODE  EBCDIC 
3  DEVICE  SIZE  # 


These  commands  set  up  device  rat-p 

t'  rate,  code  conversion 

Character  size.  They  will  normally  be  executed  remotely  since 
they  must  be  known  before  the  local  device  could  execute  the 

zzz:  ^rA::rzEzr"  --  - 

7-bit  codes  in  an  8-blt  Zd 
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Command  to  Releaf'.e  a  Device 
@  #  GIVE  BACK 

A  device  such  as  a  line  printer  can  be  captured  by  a  terminal 
through  the  process  of  setting  device  parameters  for  it.  Only  one 
terminal  can  be  in  control  of  a  device  at  a  time;  therefore,  the 
terminal  user  should  release  it  when  finished.  As  previously 
mentioned,  most  terminals  are  under  their  own  command  and  cannot 
be  captured.  A  command  attempting  to  set  up  parameters  on  a 
device  already  captured  will  be  answered  with  an  error  message. 

Commands  to  Set  Linefeed  Mode 

@  FEED  AUTO 
a  FEED  MANUAL 

When  in  AUTO  mode,  the  Terminal  IMP  will  generate  a  LINEFEED 
each  time  it  receives  a  CARRIAGE-RETURN  from  the  terminal.  The 
LINEFEED  will  be  transmitted  both  to  the  terminal  (regardless  of 
the  ECHO  mode)  and  to  the  receiving  Host.  One  of  the  consequences 
of  AUTO  mode  is  that  the  terminal  user  terminates  commands  by 
typing  only  CARRIAGE-RETURN. 

Commands  to  Follow  Standard  Protocols 


PROTOCOL 

TO 

TRANSMIT 

0 

PROTOCOL 

TO 

CLOSE  TRANSMIT 

Q 

PROTOCOL 

TO 

RECEIVE 

3 

PROTOCOL 

TO 

CLOSE  RECEIVE 

3 

PROTOCOL 

BOTH 

3 

LOGIN 

Q 

CLOSE 
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These  commands  Instruct  the  Terminal  IMP  to  follow  standard 
Host-to-Host  protocol  procedures.  The  pair  of  TRANSMIT  commands 
attempt  to  open  or  close  a  connection  for  which  the  Terminal  IMP 
is  the  sender.  Similarly,  the  pair  of  RECEIVE  commands  attempt 
to  open  or  close  a  connection  for  which  the  Terminal  IMP  is  the 
receiver.  The  BOTH  command  attempts  to  open  both  a  send  and  a 
receive  connection.  Note  that  the  Host  number  and  the  remote 
socket  number(s)  must  be  set  before  using  these  commands. 

The  LOGIN  command  instructs  the  Terminal  IMP  to  follow  the 
standard  Initial  Connection  Protocol.  The  CLOSE  command  attempts 
to  close  both  a  send  and  a  receive  connection.  It  may  be  used 
either  after  a  successful  LOGIN  or  after  establishing  both 
connections  manually. 

During  the  third  quarter  of  1971  we  will  install  the  first 
three  operational  Terminal  IMPs.  We  antxoipate  that  as  users 
gain  experience  with  the  command  language,  some  tailoring  will 
prove  desirable.  We  also  expect  to  acquire  and  test  other  types 
of  terminal  devices  with  the  MLC .  In  addition,  we  will  continue 
to  develop  and  improve  the  operation  of  the  Terminal  IMP  software. 
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